Fix 2 race conditions #1854
Merged
Fix 2 race conditions #1854
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This is a workaround but before generalizing it I would like to investigate why we send this DSP signal notification with a null sample rate in the first place. |
|
I am having an issue where the scope in the DSD Demodulator will freeze. It will work initially, but after a period of time, it will freeze. The length of time varies. I am running a Raspberry Pi 4 with Raspberry Pi OS Bookworm. ----Steve |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This PR fixes 2 race conditions in some RX demods.
The first is the initialisation of the number of streams used by a scope. Currently this is performed in the GUI, but this can be too slow, if the sink gets samples before the GUI initialisation code has run, resulting in a crash. So I've moved the init code to the baseband, where the scope is created.
The next problem appears if a channel is added to a device set that is already running. When this happens, the baseband class initially receives a DSP signal notification with a baseband sample rate of 0. This results in the DownChannelizer not being initialised properly. For some demods with low sample rates, it seems Baseband::handleData() can be called before the correct baseband sample rate is received and used to correctly initialise the DownChannelizer. When this happens, the channels will hang (somewhere in m_channelizer->feed), the log will show samples being dropped and if you try to stop the device, SDRangel will hang completely.
This patch has a little workaround for the demods I've noticed have this problem (on my computer, at least). In the handleData() method, I've added a check to make sure a valid baseband sample rate has been set in the channelizer, preventing m_channelizer->feed from being called, if not. E.g:
Old:
while ((m_sampleFifo.fill() > 0) && (m_inputMessageQueue.size() == 0))
New:
while ((m_sampleFifo.fill() > 0) && (m_inputMessageQueue.size() == 0) && m_channelizer->getBasebandSampleRate())
Is there a better way? (Perhaps DownConverter could have a isValid() method, to also check channelSampleRate is correct etc)
Should this code be added to all demod basebands? I guess the problem potentially applies everywhere.